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Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1 .704(b). 

Status 

1 )KI Responsive to communication(s) filed on 31 March 2005 . 
2a )□ This action is FINAL. 2b)^ This action is non-final. 
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DETAILED ACTION 

Status of Claims 

1. This action is in reply to the application filed on March 31, 2005. Amended claims were received 
on March 31, 2005. Claim 9 was cancelled. Claims 1-8 and 10-21 are currently pending and 
have been examined. 

2. This application claims priority to PCT/EP03/10442 filed on September 18, 2003. This application 
claims priority to EP 0202204.2 filed on October 1, 2002. A certified copy of the foreign 
application was received by the Office 



Drawings 

3. Original drawing 1 was received on March 31, 2005. Replacement drawing 1 was received on 
November 14, 2006. Drawing 1 is accepted. 



Specification 

4. The disclosure is objected to because of the following informalities: in the specification the term 
"definition instructions" is used to mean instructions that are both "interfaces" (see page 2, line 2) 
and "classes" (see page 3 line 14). Similarly, the term "implementation instructions" is used to 
mean instructions that are both "classes" (see page 2, line 3) and "interfaces." It is unclear which 
interpretation should be given to the terms. Appropriate correction is required. 
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Double Patenting 

5. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in 
public policy (a policy reflected in the statute) so as to prevent the unjustified or improper 
timewise extension of the "right to exclude" granted by a patent and to prevent possible 
harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection 
is appropriate where the conflicting claims are not identical, but at least one examined application 
claim is not patentably distinct from the reference claim(s) because the examined application 
claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., 
In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 
USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re 
Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 
619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). 

6. A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to 
overcome an actual or provisional rejection based on a nonstatutory double patenting ground 
provided the conflicting application or patent either is shown to be commonly owned with this 
application, or claims an invention made as a result of activities undertaken within the scope of a 
joint research agreement. 

7. Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. 
A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b). 

8. Claims 1-3, and, 12-14, are provisionally rejected on the ground of nonstatutory obviousness- 
type double patenting as being unpatentable over claims 1 and 11 of copending Application No. 
10/676825. Although the conflicting claims are not identical, they are not patentably distinct from 
each other because they are anticipated by the copending claims. For example, the following 
table compares claim 1 of the present application to claim 1 of the copending application: 
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Present application (10/529638) 



Copending application (10/676825) 



1. A computer-implemented method for 
validating computer code, comprising: 



providing a computer program by defining 



at least one set of implementation 
instructions 



at least one set of definition instructions, 



validating the set of definition instructions 
and the set of implementation instructions 
using a validation tool 



and at least a script code section; 



validating the script code section using 
the set of implementation instructions. 



1. A method for validating programs, the 
method comprising steps implemented by one 
or more computers of: 

receiving a meta-language description of a 
computer program, the meta- language 
description comprising 

a meta-language definition module and 

a meta- language implementation module, the 
meta-language implementation module defining 
a first class to be implemented by the computer 
program and the meta-language definition 
module defining a first interface associated with 
the class; 



validating the meta-language description by 
validating syntax of the meta-language 
definition module and syntax of the meta- 
language implementation module; 

generating a language-dependent program 
from the meta-language description, the 
language-dependent program comprising the 
first interface, the first class 

and a script code section written in a scripting 
language 

performing usage and semantic checks on the 
computer program by compiling the generated 
first interface and the generated first class; and 
performing usage checks on the script code 
section by extracting language elements from 
the generated script code section and 
comparing the extracted language elements 
with the meta-language definition module used 
to generate the language-dependent program. 
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9. Note that in the present application, the "definition instructions" are defined as "classes" in claims 
2 and 3, whereas the "implementation instructions" are defined as "interfaces" in claims 2 and 3. 
Thus, the "definition instructions" of the present application have an equivalent function to the 
"implementation module" of the copending application. This inconsistency in terminology is 
further addressed in a rejection under 35 (JSC 112, 2nd paragraph, below. 

10. Thus, "validating the script code with the implementation instructions ," as in the present claim 1, 
is equivalent to "comparing the extracted language elements with the meta-lanquaqe definition 
module ", as in the copending claim 1. 

11. Claims 12-14 are computer readable medium versions, which recite the same limitations of 
claims 1-3. The computer readable medium is anticipated by the computer program product of 
claim 11 of the copending application. 

12. Claims 4-6, 10-11, 15-17, and 20-21, are provisionally rejected on the ground of nonstatutory 
obviousness-type double patenting as being unpatentable over claims 1 and 11 of copending 
Application No. 10/676825 in view of "Java and XML Data Binding" (McLaughlin, 2002). Although 
the conflicting claims are not identical, they are not patentably distinct from each other because 
they would have been obvious over the copending claims in view of the cited art. 
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13. As to claims 4,6, 10-11, 15, 17, and 20-21 , in addition to the limitations of the parent claims being 
wholly anticipated by the copending claims as discussed above, McLaughlin further teaches the 
set of definition instructions ("XML documents") and the set of implementation instructions ("XML 
constraints") are described in XML (see at least section 2.3.1 , particularly "XML file" and figure 2- 
2 "XML documents" and section 2.3, particularly "XML constraints"). It is readily apparent that 
McLaughlin teaches the files are in a tree structure because the files are XML files. It would have 
been obvious to one of ordinary skill in the art at the time the invention was made to combine the 
meta-language instructions of the copending claim 1 with the XML of McLaughlin because XML 
("extensible Markup Language") is a common type of meta-language. 

14. As to claims 5 and 16, in addition to the limitations of the parent claims being obvious over the 
copending claims and cited art as discussed above, McLaughlin further teaches the classes and 
the interfaces are defined in Java language (see at least section 3.1.4, figure 3-1, particularly: 
"The result of the generation step is one or more Java source files"). It would have been obvious 
to one of ordinary skill in the art at the time the invention was made to combine the language- 
dependent program of the copending claims 1 and 11 with the Java language of McLaughlin 
because Java is a common language for language-dependent programs. 

15. Claims 7-8 and 18-19, are provisionally rejected on the ground of nonstatutory obviousness-type 
double patenting as being unpatentable over claims 1 and 11 of copending Application No. 
10/676825 in view of Lucas et al. (US 6,754,884 B1). Although the conflicting claims are not 
identical, they are not patentably distinct from each other because they would have been obvious 
over the copending claims in view of the cited art. 
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16. As to claims 7 and 18, in addition to the limitations of the parent claims being wholly anticipated 
by the copending claim as discussed above, Lucas further teaches that the script code section is 
JavaScript (see at least column 3, lines 45-55, particularly "a scripting language, such as 
JavaScript"). It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the scripting language of the copending claim 1 with the 
JavaScript of Lucas because JavaScript is a common scripting language. 



17. As to claims 8 and 19, in addition to the limitations of the parent claims being obvious over the 
copending claims and cited art as discussed above, Lucas further teaches that validating the 
script code section comprises generating a symbol table by executing the code section in an 
interpreter ("parser"), and comparing the symbol table with the implementation instruction ("XML 
data type declarations") (see at least column 3, line 56 through column 4 line 7, particularly: "a 
JavaScript-aware parser (e.g. parser 105) is equipped to recognize XML data type declarations 
and associate them with the appropriate items in the corresponding symbol table"). It would have 
been obvious to one of ordinary skill in the art at the time the invention was made to combine the 
validation of the copending claim 1 with the validation using the symbol table of Lucas because it 
would allow validating a script-based web service with XML constraints (column 3 lines 45-55). 



18. This is a provisional obviousness-type double patenting rejection because the conflicting claims 
have not in fact been patented. 
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Claim Rejections - 35 USC §112 

19. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

20. Claims 2-5 and 13-16 are rejected under 35 U.S.C. 112, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. 

21 . The term "definition instructions" in claims 2, 3, 13, and 14 is used by the claim to mean "classes." 
However, in the specification the term "definition instructions" is used to mean instructions that 
are both "interfaces" (see page 2, line 2) and "classes" (see page 3 line 14). Classes and 
interfaces are further described in the specification as to their functionality, in a manner consistent 
with that known in the art. Thus, the term as used in the claims is indefinite because it is unclear 
which interpretation should be given to the term. 

22. Similarly, the term "implementation instructions" in claims 2, 3, 13, and 14 is used by the claim to 
mean "interfaces." However, in the specification the term "implementation instructions" is used to 
mean instructions that are both "classes" (see page 2, line 3) and "interfaces" (see page 3 line 
14). Thus, the term as used in the claims is indefinite because it is unclear which interpretation 
should be given to the term. 

23. Under the principles of compact prosecution, examiner treats the definition instructions as 
classes, and the implementation instructions as interfaces, as set forth in the claims. In the 
double patenting rejection, the two claims are treated as functionally equivalent because the 
instructions which are classes have one function, and the instructions which are an interface have 
a different function. 



24. 



Claims 4-5 and 15-16 are rejected as depending from rejected claims. 
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Claim Rejections - 35 USC §103 

25. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 
rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

26. Claims 1-8 and 10-21 are rejected under 35 U.S.C. 103(a) as being unpatentable over "Java and 
XML Data Binding" (McLaughlin, 2002) in view of Lucas et al. (US 6,754,884 B1 ). 

Claim 1 

McLaughlin teaches a computer-implemented method for validating computer code (see 
at least section 3.1.4, Figure 3-1 validating Binding schema against DTD). McLaughlin further 
teaches providing a computer program by defining at least one set of definition instructions ("XML 
document") and at least one set of implementation instructions ("constraint model") (see at least 
section 3.1.1). McLaughlin further teaches validating the set of definition instructions ("XML 
document") and the set of implementation instructions ("constraint model") using a validation tool 
(see at least section 3.1 .1 , particularly "ensure that your constraint model syntax is supported by 
the binding framework you want to use" and "Write several XML documents ... and validate them 
against your new constraints.") 

McLaughlin further teaches a computer program comprises other web services (see at 
least section 1.2.2, particularly "web services"). However, McLaughlin does not explicitly teach a 
script code section. Lucas teaches a script code section (see at least column 3, lines 45-55, 
particularly "XML-oriented language extensions for use in association with a scripting language"). 
Lucas further teaches validating the script code ("JavaScript") section using the set of 
implementation instructions ("XML data type declarations") (see at least column 3, line 56 through 
column 4 line 7, particularly: "a JavaScript-aware parser (e.g. parser 105) is equipped to 
recognize XML data type declarations and associate them with the appropriate items in the 
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corresponding symbol table"). It would have been obvious to one of ordinary skill in the art at the 
time the invention was made to combine the constraint model of McLaughlin with the script code 
validation of Lucas because it would allow XML constraints to be used and tested with a script- 
based web service (see at least McLaughlin section 1.2.2 and Lucas column 3 lines 45-55). 

Claim 2 

Claim 2 includes all of the limitations of claim 1 . McLaughlin further teaches the set of 
definition instructions are classes (see at least section 2.3.1 , particularly "XML file" and figure 2-2 
"XML documents"). It is readily apparent that XML documents are classes because they contain 
the functions and data of the program. McLaughlin further teaches the set of implementation 
instructions are interfaces (see at least section 2.3, particularly "XML constraints" and section 
6.4.4 "Interfaces, particularly: "To generate an interface, add this statement to your binding 
schema"). Because XML constraints are a model of the behavior of classes ("XML document"), 
they are an interface. 

Claim 3 

Claim 3 includes all of the limitations of claim 1 . McLaughlin further teaches the set of 
definition instructions are converted into classes (see at least section 3.1 .4, figure 3-1 "Class 
generation process flow" and "The result of the generation step is one or more Java source files"). 

McLaughlin further teaches the set of implementation instructions are converted into 
interfaces (see at least section 6.4.4 "Interfaces", particularly "The result of this statement is a 
new generated class, the Person interface"). 

Claims 4, 6, 10, and 11 

Claim 4 includes all of the limitations of claim 3. Claims 6, 1 0 and 1 1 include the 
limitations of claim 1 . McLaughlin further teaches the set of definition instructions ("XML 
documents") and the set of implementation instructions ("XML constraints") are described in XML 
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(see at least section 2.3.1 , particularly "XML file" and figure 2-2 "XML documents" and section 
2.3, particularly "XML constraints"). It is readily apparent that McLaughlin teaches the files are in 
a tree structure because the files are XML files. 

Claim 5 

Claim 5 includes all of the limitations of claim 4. McLaughlin further teaches the classes 
and the interfaces are defined in Java language (see at least section 3.1 .4, figure 3-1 , particularly: 
"The result of the generation step is one or more Java source files"). 

Claim 7 

Claim 7 includes all of the limitations of claim 1 . McLaughlin further teaches a computer 
program comprises other web services (see at least section 1 .2.2, particularly "web services"). 
However, McLaughlin does not explicitly teach a script code section. Lucas teaches the script 
code section is JavaScript (see at least column 3, lines 45-55, particularly "a scripting language, 
such as JavaScript"). It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to combine the constraint model of McLaughlin with the JavaScript script 
code validation of Lucas because it would allow XML constraints to be used and tested with a 
script-based web service (see at least McLaughlin section 1 .2.2 and Lucas column 3 lines 45-55). 

Claim 8 

Claim 8 includes all of the limitations of claim 1 . McLaughlin further teaches validating 
the script code section comprises generating a symbol table by executing the code section in an 
interpreter ("parser"), and comparing the symbol table with the implementation instruction ("XML 
data type declarations") (see at least column 3, line 56 through column 4 line 7, particularly: "a 
JavaScript-aware parser (e.g. parser 105) is equipped to recognize XML data type declarations 
and associate them with the appropriate items in the corresponding symbol table"). It would have 
been obvious to one of ordinary skill in the art at the time the invention was made to combine the 
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constraint model of McLaughlin with the script code validation of Lucas because it would allow 
validating a script-based web service with XML constraints (see at least McLaughlin section 1 .2.2 
and Lucas column 3 lines 45-55). 

Claims 12-21 

Claims 12-21 are a computer readable medium version, which otherwise recites the 
same limitations of the claims 1-8 and 10-11. The combination of McLaughlin and Lucas teaches 
all of the limitations of claims 1-8 and 10-11. It is readily apparent that the method taught by 
McLaughlin includes instructions to implement the method on a computer readable medium (see, 
for example, section 3.1 step 4, "compile the classes"). 

Cited Prior Art 

27. Hammerich et al. (US PG-PUB 2004/0123273 A1, hereafter '273) is cited as claiming priority to 
the same European application (EP 02022042.2). Hammerich et al. (US 7,584,457) is cited as 
being a granted patent from application '273. 

28. Examiner's Note: The Examiner has pointed out particular references contained in the prior art 
of record within the body of this action for the convenience of the Applicant. Although the 
specified citations are representative of the teachings in the art and are applied to the specific 
limitations within the individual claim, other passages and figures may apply. Applicant, in 
preparing the response, should consider fully the entire reference as potentially teaching all or 
part of the claimed invention, as well as the context of the passage as taught by the prior art or 
disclosed by the Examiner. 

Conclusion 

29. Any inquiry of a general nature or relating to the status of this application or concerning this 
communication or earlier communications from the Examiner should be directed to Erika 
Kretzmer whose telephone number is (571) 270-5554. The Examiner can normally be reached 
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Monday through Thursday, 9:30am-6:00pm Eastern Time. If attempts to reach the examiner are 
unsuccessful, the Examiner's supervisor, Tuan Dam can be reached at (571) 272-3695. 

30. Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be 
obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR system, 
see http://portal.uspto.gov/extemal/portal/pair . Please direct questions on access to the Private 
PAIR system to the Electronic Business Center (EBC) at 866.217.9197 (toll-free). 

31 . Any response to this action should be mailed to: 



or faxed to 571-273-8300. Hand delivered responses should be brought to the United States 
Patent and Trademark Office Customer Service Window: 



Commissioner of Patents and Trademarks 



Washington, D.C. 20231 



Randolph Building 



401 Dulany Street 



Alexandria, VA 22314. 



/Erika Kretzmer/ 



/Eric B. Kiss/ 
Eric B. Kiss 

Primary Examiner, Art Unit 2192 



Examiner, Art Unit 2192 



August 26, 2009 



